Design verification is essential to virtually any very large scale integration (VLSI) design project. One of the popular verification methods is logic simulation. Logic simulation software reports on how a circuit under design responds to a sequence of input vectors, so the designer can judge whether the circuit behaves as expected over the input sequence. The more vectors simulated, the greater confidence the designer has in the correctness of the designing circuit.
As circuit complexity increases and the time to market shortens, inadequate simulation speed becomes a major bottleneck in the design process. As a result, several special purpose machines have been built to simulate/emulate complex logic designs in hardware, rather than software. Such emulation/acceleration devices can provide several orders of magnitude of speed improvement during the simulation/emulation process. Thus, the necessity and usefulness of emulation/acceleration devices has increased enormously with growth in the complexity of integrated circuits.
An emulation/acceleration engine operates to mimic the logical design of a set of one or more integrated circuit chips. The emulation of these chips in terms of their logical design is highly desirable for several reasons which are discussed in more detail below. It is, however, noted that the utilization of emulation/acceleration engines has also grown up with and around the corresponding utilization of design automation tools for the construction and design of integrated circuit chip devices. In particular, as part of the input for the design automation process, logic descriptions of the desired circuit chip functions are provided. The existence of such software tools for processing these descriptions in the design process is well mated to the utilization of emulation/acceleration engines which are electrically configured to duplicate the same logic function that is provided in a design automation tool.
Utilization of emulation/acceleration devices permits testing and verification, via actual electrical circuits, of logical designs before these designs are committed to a so-called “silicon foundry” for manufacture. The input to such foundries is the functional logic description required for the chip, and its output is initially a set of photolithographic masks which are then used in the manufacture of the desired electrical circuit chip devices. However, it is noted that the construction of such masks and the initial production of circuit chips, which operate in accordance with the designed for functional logic requirements, is expensive. Any passage of a given device having the prescribed logic functionality though such a foundry is an expensive and time consuming process which clearly should be undertaken only once. It is the purpose of emulation/acceleration engines to ensure such a single passage from the functional logic design stage through the stage of chip production via such a foundry.
Verifying that logic designs are correct before committing a design to manufacturing, therefore, eliminates the need for costly and time-consuming multiple passes through a silicon foundry. Debugging logic errors deep inside a logic chip can be extremely difficult because of very limited observability. Emulation provides two very significant advantages. Firstly, the proper verification of a functional logic design eliminates the need for a second costly passage through the foundry, and, secondly, and just as importantly, getting the design “right the first time” means that the design does not have to be corrected in the foundry. Accordingly, production delays are significantly reduced and the time to market for the particular technology/technology improvements embedded in the integrated circuit chip is greatly reduced, thus positively impacting the ability to deliver the most sophisticated technological solutions to consumers in as short of time as possible.
An additional advantage that emulation/acceleration systems have is that they act as a functioning system of electrical circuits which makes possible the early validation of software which is meant to operate the system that the emulator/accelerator is mimicking. Thus, software can be designed, evaluated and tested well before the time when the system is embodied in actual circuit chips. Additionally, emulation/acceleration systems can also operate as simulator-accelerator devices thus providing a high speed simulation platform.
FIG. 1A illustrates a high-level block diagram of a typical emulation/acceleration system 10 (hereinafter referred to as emulation system 10), which is controlled by a host workstation 12. Emulation system 10 includes at least one emulation board 14, which, in turn, contains a plurality of emulation modules 16, as shown in FIG. 1B. Each emulation module 16 contains a plurality of emulation processors 18, as shown in FIG. 1C. Each emulation processor 18 is programmed to evaluate a particular logic function (for example, AND, OR, XOR, NOT, NOR, NAND, etc.). The programmed emulation processors 18, together as a connected unit, emulate the entire desired logic design under test 19 (i.e., the programmed emulation processors form part of a simulation “model” 15 for the logic design). This simulation model 15 may also include some additional controllability/observability logic to aid in the simulation/emulation process.
The overall simulation throughput of such a system is limited by the interface between the simulation model running on the emulation system 10 and a control program 20 running on a host workstation 12. Transactions between control program 20 and the emulation board 14 include reading and writing the values of logic facilities contained within the simulation model and the execution of cycles to recalculate the model state by toggling the value of clock signals that propagate to latch facilities within the simulation model.
The propagation of a “clock” command from control program 20 to emulation system clock distribution circuitry 24 through a normal network interface 26 incurs a substantial latency, particularly if the number of cycles specified by the “clock” command is low, and the speed of emulation system 10 is high.
In order to address this shortcoming, some systems provide an alternate communication path between control program 20 and the emulation board 14 that bypasses normal network interface 26. This path includes a custom stimulus card 28 (e.g., Cadence Design System's Direct Access Stimulus “DAS” card) plugged into a PCI slot in host workstation 12. A special high-speed multi-strand cable 30 is connected between custom stimulus card 28 and the emulation board 14 containing the model. This cable 30 is much more efficient than the network interface 26 because of the more direct connection. To use this cable 30 most efficiently, a single “cycle forever” command is issued from control program 20 to emulation board 14 via network interface 26. Emulation system 10 then continuously evaluates the model state. Read and write accesses from control program 20 through custom stimulus card 28 then directly accesses the model facilities as they are being evaluated.
In order to keep control program 20 synchronous with the evaluation of the emulation model, precise control of the clocking signals to all latches within the model is required. In order to prevent an undesired change in model state, the clock signals should be disabled while the emulation system 10 is cycling. This condition where in the emulator is cycling but the model is prohibited from changing state is known as “idling”. Clock signals should be enabled for the precise number of emulator cycles in order to allow the model to change state. In one implementation, one of the signals on cable 30 is assigned to a clock signal that, when toggled, produces a 1-emulator-cycle pulse in the model, advancing the model to the next sequential state. Control program 20 then executes a loop that toggles the clock signal for the required number of cycles.
While this technique provides an improvement over the network interface 26 method of clocking, it still does not provide optimum obtainable throughput. There is a need for an enhanced apparatus and method for controlling the clock inputs to all latches within the simulation model. Such an apparatus should reside within the emulation board 14, so that work previously performed by a clock control loop in control program 20 is now performed by logic within the emulation board 14 itself.